GDBRemote: chdir ds2 itself when the platform working directory is set - #249

… directory

onFileOpen and its siblings in FileOperationsMixin passed vFile paths
straight through to Host::File, never consulting the working directory
set via QSetWorkingDir, unlike qPlatform_shell and process launch. This
is why lldbutil.wait_for_file_on_target's ls-then-Get() sequence
diverged: the shell-based ls resolves relative paths against the
platform working directory (qPlatform_shell carries an explicit cwd
field), but the vFile:open packet that immediately follows carries no
such field, so ds2 has no way to know it unless it tracks the field
from QSetWorkingDir itself.

Resolve relative vFile paths against each session's own
_workingDirectory rather than ds2's actual process cwd: PlatformMain in
Sources/main.cpp serves every connected platform client on its own
thread with its own PlatformSessionImpl, so the process cwd is shared,
mutable state across all of them, and mutating it per-session would let
concurrent clients stomp on each other's working directory.

onSetWorkingDirectory canonicalizes the incoming path to absolute the
moment it's set (a relative path only means something relative to
ds2's own starting directory, since ds2's cwd never changes), rather
than storing it verbatim. This also keeps ProcessSpawner's own chdir()
in the forked child working correctly for a relative QSetWorkingDir:
storing the raw relative string and letting both the vFile join and
the spawner's chdir() apply it independently would resolve it against
two different bases and risk applying it twice.

Verified against a rebuilt android-x86_64 ds2 on the local emulator:
TestHelloWorld.test_with_attach_to_process_with_id_api passes (was
failing with "unable to open source file"); a raw protocol probe
confirms a relative QSetWorkingDir resolves once (no doubling) and that
two concurrent sessions keep independent working directories; and the
sanity/api/android categories show no regressions.